Thank you for proposing a fix. Unfortunately, this is not usually the right way to ensure motion completion. It is intentional that SetPositionUm and related functions return before the movement finishes. (This is so that actions of other devices can be started from the same thread.)

Instead, there is a Busy function that is supposed to return true if the stage has not completed the last motion. In the Standa8SMC4 devices, it seems to be implemented using the get_status() function from the device API.

The Busy function is what is used when the application waits for a device, for example by calling the Core method: mmc.waitForDevice("label"); in the Script Panel.

Can you maybe test if the Busy function is behaving incorrectly and see if it can be fixed?

Thanks for the quick answer!

Thank you for proposing a fix. Unfortunately, this is not usually the right way to ensure motion completion. It is intentional that SetPositionUm and related functions return before the movement finishes. (This is so that actions of other devices can be started from the same thread.)

I see! This raises a question a bit unrelated. How is it supposed to work with systems that their API only have blocking calls (so it waits for the movement to finish before returning)? I'm asking because I wrote a wrapper around another stage and this is the case for it. There's no non-blocking call method so I implemented in a blocking way.

Can you maybe test if the Busy function is behaving incorrectly and see if it can be fixed?

Will do!

How is it supposed to work with systems that their API only have blocking calls (so it waits for the movement to finish before returning)?

Our device interface is rather inconvenient in this case.

To behave correctly, the blocking call would have to be made on a separate thread created by the device adapter. It might make sense to issue all calls to such an API from a dedicated thread (so that there is no danger of them overlapping), and have the rest of the code (i.e. interface to MMCore) interact with that thread through message queues. This usually requires a fairly significant programming effort.

In some cases, a compromise could be made where the set-position functions block until the motion is complete. This is often "good enough" for faster devices (e.g. piezo stages). It is not ideal for motor-driven devices, but could be better than not having support for that device.